• pnpm-lock.yaml: Generated file

apps/ledger-live-desktop/src/mvvm/features/AnalyticsConsentDialog/hooks/useAnalyticsConsentDialogViewModel.ts:50

• policyVersion can fall back to the stored privacyPolicyVersion, which may still be a legacy number (e.g. 1). Persisting/tracking that value keeps it unnormalized, even though the new flow expects normalized "<major>.<minor>" versions (and tests now assert "1.0"). Consider normalizing the numeric fallback before using it.

  const policyVersion = currentPolicyVersion?.normalized ?? consentInfo.privacyPolicyVersion;

apps/ledger-live-desktop/src/mvvm/features/AnalyticsOptInPrompt/hooks/useCommonLogic.tsx:37

• policyVersion falls back to consentInfo.privacyPolicyVersion, which may still be a legacy number (e.g. 1). That would be persisted as-is on submit, leaving the stored policy version unnormalized. Normalizing numeric fallbacks here keeps persisted values consistent with the new "<major>.<minor>" policyVersion format.

  const policyVersion = currentPolicyVersion?.normalized ?? consentInfo.privacyPolicyVersion;

• pnpm-lock.yaml: Generated file

apps/ledger-live-desktop/src/renderer/screens/settings/sections/Developer/AnalyticsConsentOptInDevTool/AnalyticsConsentOptInDevScreen.tsx:160

• The "Stored privacy policy version" status is currently derived from decision.kind !== "none", which also turns the stored-version line red for renewals caused only by an invalid/missing consent date. That makes the QA screen misleading because the stored policy version may still be up to date when renewal is purely date-driven.

Consider flagging an error state here only when the decision is privacy-related, or when renewal is specifically caused by stored version issues / major bump.

                className={`min-w-0 flex-1 body-2 font-medium leading-relaxed ${
                  decision.kind !== "none" ? "text-error" : "text-success"
                }`}

• pnpm-lock.yaml: Generated file

apps/ledger-live-desktop/src/mvvm/features/AnalyticsOptInPrompt/hooks/useCommonLogic.tsx:38

• policyVersion can fall back to consentInfo.privacyPolicyVersion, which may be a legacy number (e.g. 1) or a non-normalized string (e.g. "1"). That contradicts the PR’s intent of persisting a normalized "<major>.<minor>" version and can lead to mixed formats in persisted settings and analytics payloads.

Consider normalizing legacy values before persisting/tracking (at least normalize pure-integer values to "<n>.0", and keep invalid strings as-is).

  const { currentPolicyVersion } = resolveAnalyticsOptInParams(analyticsOptInFlag);
  const policyVersion = currentPolicyVersion?.normalized ?? consentInfo.privacyPolicyVersion;
  const shouldWeTrack = isTrackingEnabled || !hasSeenAnalyticsOptInPrompt;

apps/ledger-live-desktop/src/mvvm/features/AnalyticsConsentDialog/hooks/useAnalyticsConsentDialogViewModel.ts:51

• policyVersion falls back to the stored privacyPolicyVersion, which can still be a legacy number (e.g. 1) or non-normalized string (e.g. "1"). If that value is reused in tracking payloads or persisted on future updates, it can reintroduce mixed policy-version formats even though the shared flow normalizes to "<major>.<minor>".

Normalizing pure-integer values here keeps the persisted/telemetry format consistent without changing behavior for invalid stored versions.

  const { isFeatureEnabled, decision, currentPolicyVersion } =
    useAnalyticsConsentDecision(consentInfo);
  // An invalid remote version must not erase the version the user already acknowledged.
  const policyVersion = currentPolicyVersion?.normalized ?? consentInfo.privacyPolicyVersion;